AADSTS50000: There was an error issuing a token or an issue with our sign-in service

This error can occur during Azure AD authentication process or during any token acquisition flow using the token endpoint. There are multiple causes for this error to happen. Below are a few scenarios that can lead to the error .

Root Cause 1: the user password is either expired, invalid, or out of sync

This can happen more predominantly in a hybrid environment. The authenticated federated account’s password may be out of sync between the on-prem Active Directory and Azure AD. This can also happen when a user session is being revoked.

Resolution:

Reset the user password and verify the new password can authenticate successfully to Azure AD.

Root Cause 2: certain parameters in the token acquisition request are either missing or invalid

Resolution:

This scenario is more applicable in Azure AD’s On-Behalf-Of (OBO) flow. Make sure the client ID is valid and other required parameters are not missing. See this reference and this reference for more info.

Root Cause 3: Consent related issue

This can happen in an OAuth2 Device code grant flow to the token endpoint. After the user signs in to a browser window and accepts the consent dialog, this error occurs.

Resolution:

Check to make sure both of the following requirements are satisfied:

1. The client application (Service Principal) performing the sign in exists in the tenant’s Enterprise Applications blade. You can search for the Application by App ID.
2. User has the ability to consent to the Application. Check the User Settings in Enterprise Applications blade, or any other relevant policies affecting user consent.

Root Cause 4: There is a signing symmetric key attached to either the Application or the Service Principal Object.

Microsoft Identity Platform (v2 endpoint) can only issue tokens signed by a certificate (asymmetric key). Asymmetric signing key is always more preferable than a signing symmetric key for security reason since the private key never leaves the authorization server. By default Azure AD always issues tokens signed with a certificate. See signing key rollover documentation for more detail.

Check if there is a symmetric key attached to the Application object:

Go to the Application in the App Registrations blade in Azure Active Directory and click on the Manifest section. Check to see if there is an entry in the keyCredentials section with type=Symmetric and usage=Sign.

Alternatively you can also use also use the AzureAD PowerShell commandlet Get-AzureADApplicationKeyCredential to see the keyCredential info.

Check if there is a symmetric key attached to the ServicePrincipal object:

If you can’t find the Application in the App Registrations blade, check the Enterprise Application blade to see if the application exists there. If it exists get the Object ID of the Service Principal in the Overview blade and run the AzureAD PowerShell commandlet Get-AzureADServicePrincipalKeyCredential with that Object ID to see the keyCredential info.

Resolution:

Remove the symmetric signing key (if existed) from that Application or Service Principal object. Depending on where where the symmetric signing key is attached, you can use either the PowerShell commandlet Remove-AzureADServicePrincipalKeyCredential or Remove-AzureADApplicationKeyCredential to do that. If you need to attach a signing key for the application, use a certificate instead. Review this blog for more info.

Note: If you encounter a signature validation error after adding a signing certificate to the application, see this post for how to resolve the issue.

Root Cause 5: The resource application (web API) does not have any delegated permission exposed

This error can happen in the following scenario: You have a multi-tenant (resource) application registered in tenant A. This application exposes only Application Permission type. In a different tenant (let’s call this tenant B), you have a client application registered and in the ‘API permission’ blade for this application configure the permission for the resource application registered in the other tenant. You then use an OAuth 2 delegated grant flow (for instance auth code grant flow) to request an Access Token for the resource app using the /ldefault for the web API scope.

Resolution:

Configure the resource application to also expose Delegated permission and consent to that Delegated permission in the client application.